Secure payment card transactions

ABSTRACT

Payment card transactions at a point of sale (POS) are secured in certain embodiments by intercepting, with a POS security layer installed on a POS terminal, payment data from the POS terminal, transmitting the payment data from the POS security layer to a server security application installed on a POS server, and providing false payment data from the POS security layer to a POS terminal application installed on the POS terminal. The false payment data in various embodiments is processed as if it were the payment data, such that the POS terminal transmits an authorization request to the POS server using the false payment data. In addition, the authorization request may be transmitted from the POS server to a payment gateway.

RELATED APPLICATIONS

The present application claims priority benefit under 35 U.S.C. §120 toand is a continuation of the following U.S. patent applications:

-   Ser. No. Title Filed Attorney Docket No.-   Ser. No. 11/750,181 Secure Payment Card Transactions May 17, 2007    SHIFT4.001A-   Ser. No. 11/750,239 (Now U.S. Pat. No. 7,770,789) Secure Payment    Card Transactions May 17, 2007 SHIFT4.002A-   Ser. No. 11/750,184 (Now U.S. Pat. No. 7,841,523) Secure Payment    Card Transactions May 17, 2007 SHIFT4.003A

The present application incorporates the foregoing disclosures herein byreference in their entirety.

BACKGROUND

1. Field

The present disclosure relates to payment systems.

2. Description of the Related Art

The use of payment cards such as credit cards, debit cards, and giftcards has become ubiquitous in our current commercial transactionsociety. Virtually every merchant, as well as other facilities wheremonetary transactions occur for the purchase of goods or services,accept one or more types of payment cards for these transactions. Once apayment card is presented to a particular merchant at a point of sale topurchase goods or services, the payment card is usually read using acard swipe reader. Alternatively, payment data is entered manuallythrough a pin pad or keyboard or through a combination of card swipe andmanual entry.

The payment data is transmitted to an authorizing entity, which may be acard processor, card association, issuing bank, or other entity, alongwith information relating to purchase price and identificationinformation of the particular merchant. In some instances, theinformation passes through one or more intermediaries before reachingthe authorizing entity. The authorizing entity approves or disapprovesthe transaction. Once a decision is made at the authorizing entity, areturn message is sent to the merchant indicating the disposition of thetransaction.

As payment card transactions become more ubiquitous, so do thefts ofpayment data. Thefts can come from many sources, including employees,malicious software, and hardware devices for intercepting payment data.Perpetrators obtain payment data, including personal account numbers(PANs), personal identification numbers (PINs), expiration dates, andthe like, for purposes of committing fraud. In some instances, thievesuse the payment data to obtain goods, services, and cash. In otherinstances, perpetrators sell payment data to others who fraudulently usethe cards. These thefts often occur at the point of sale.

SUMMARY

Payment card transactions at a point of sale (POS) are secured incertain embodiments by intercepting, with a POS security layer installedon a POS terminal, payment data from the POS terminal, transmitting thepayment data from the POS security layer to a server securityapplication installed on a POS server, and providing false payment datafrom the POS security layer to a POS terminal application installed onthe POS terminal. The false payment data in various embodiments isprocessed as if it were the payment data, such that the POS terminaltransmits an authorization request to the POS server using the falsepayment data. In addition, the authorization request may be transmittedfrom the POS server to a payment gateway.

Neither this summary nor the following detailed description purports todefine the inventions. The inventions are defined by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary block diagram illustrating a prior artpoint-of-sale system;

FIG. 2 is an exemplary block diagram illustrating an embodiment of apoint-of-sale system;

FIG. 3 is an exemplary process-flow diagram illustrating an embodimentof a payment card authorization process;

FIG. 4 is an exemplary process-flow diagram illustrating anotherembodiment of a payment card authorization process;

FIG. 5 is an exemplary flowchart diagram illustrating an embodiment of aprocess for invoking a security component;

FIG. 6 is an exemplary flowchart diagram illustrating another embodimentof a process for invoking a security component;

FIG. 7 is an exemplary flowchart diagram illustrating an embodiment of aprocess for encrypting payment data;

FIG. 8 is an exemplary block diagram illustrating certain embodiments ofpayment data; and

FIG. 9 is an exemplary flowchart diagram illustrating an embodiment of aprocess for performing incremental authorizations or settlements.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Specific embodiments of the inventions will now be described withreference to the drawings. These embodiments are intended to illustrate,and not limit, the present inventions. The scope of the inventions isdefined by the claims.

The term “payment card” encompasses at least credit cards, debit cards,bank cards, smart cards, automatic teller machine (ATM) cards, and giftcards. In addition, other forms of payment may be interchangeable withthe payment cards described herein, including RFID-enabled devices,wireless devices, and other electronic or magnetic devices that containpayment data. In addition, although the term payment card is usedthroughout, certain embodiments of the systems and methods may also beused to process identification cards such as drivers' licenses, securityaccess cards, check cashing cards, and the like. For instance, insteadof obtaining authorization of a payment card, various embodiments of thesystems and methods described herein may be used to securely transmitand store identification card data.

To further illustrate the problems of currently available paymentsystems, FIG. 1 depicts a prior art payment system at a point of sale.The point of sale can be a payment point at a merchant's place ofbusiness to which a customer presents a payment card for purchase orrental of goods and services. The point of sale can also be consideredmore generally as the merchant's place of business. The point of salemay include, for example, a cash register, a payment interface at a gaspump, a restaurant cashier, a front desk at a hotel, a rental car desk,or the like. In some locations, such as hotels, there may be multiplepoints of sale, such as at the front desk, at a restaurant, and at agift shop. Regardless of the location of the POS 20, payment data isoften not transmitted securely from one point to another and/or storedwithout adequate protection.

The payment system includes a POS terminal 20. The POS terminal 20includes a card entry device 2 and a host computer 6. The card entrydevice 2 is a pin pad, card swipe reader, computer keyboard, or thelike, and is used to capture or enter the payment data. The card entrydevice 2 transmits the payment data to the host computer 6 over link 4,which is a cable or the like. The host computer 6 may be a cashregister, workstation, desktop computer, or the like.

In many cases, the link 4 is not secure because encryption is not usedon the link 4 to protect the payment data. However, even when encryptionis used, the card entry device 2 will still not be secure between thepoint of receiving the payment data and the point of encryption. Asoftware or hardware keylogger, for example, residing on the card entrydevice 2 or even on the host computer 6 could intercept the payment dataprior to the encryption of that data. Thus, both the card entry device 2and the link 4 are vulnerable to payment data theft.

The host computer 6 executes a POS terminal application 10. The POSterminal application 10 is responsible for receiving the payment datafrom the card entry device 2. The POS terminal application 10 sends thepayment data along with an authorization request, to determine whetherthe payment card has sufficient funds, to a POS server 8 over a network12. Like the card entry device 2, the POS terminal application 10 on thehost computer 6 might be compromised by malware, spyware, keyloggers,viruses, or the like. In addition, the network 12 may transferunencrypted payment data to the POS server 8, creating vulnerabilitiesto packet sniffers, which intercept and log network traffic.

The POS server 8 is a computer typically located at the merchant's placeof business or at a remote location owned and operated by the merchant.The POS server 8 executes a POS server application 14, which receivesthe payment data and authorization request from the POS terminalapplication 10. The POS server application 14 transmits the payment datafor authorization to a gateway 22, which requests authorization from acard processor in communication with an authorizing entity.

The POS server application 14 also stores transaction data and log data,both of which include the payment data, in a database 16. Transactiondata is stored to enable the merchant to process incrementalauthorizations and settlements, such as a restaurant tip authorizationsand rental car returns (see FIG. 9 for additional details). Log data isstored, among other reasons, for a technician to be able to troubleshootthe POS terminal 20. A drawback to storing payment data at the POSterminal 20 is that numerous payment card numbers are stored inunencrypted form in a single location, providing relatively easy accessfor a thief to obtain this unprotected data.

Turning to FIG. 2, an improved POS system is shown, which reduces oreliminates at least some of the problems found in the art. Variouscomponents of the POS system protect payment data at the card entrydevice 28 and during transit from a POS terminal 30 to a POS server 36.In addition, various components of the POS system reduce the amount ofpayment data stored at the merchant's place of business. Consequently,certain embodiments of the POS system overcome some or all of theproblems described above.

The POS terminal 30 is a computer system for receiving payment data andrequesting payment card authorizations. For example, the POS terminal 30might be a computer terminal and card swipe device at a grocery checkoutline. The POS terminal 30 of certain embodiments includes a combinationof software and hardware components.

A business might have multiple POS terminals 30, each communicating witha single POS server 36. Some hotels, for instance, include POS terminals30 at the front desk, in the hotel restaurant, and in the hotel giftshop, all of which are connected by a network to a common POS server 36.In another example, a retail or grocery store might include POSterminals 30 at each checkout line.

The POS terminal 30 and POS server 36 may be identical to the POSterminal and server of the prior art system of FIG. 1 but augmented witha POS security layer (PSL) 40 and server security application (SSA) 48.These two software components can be added to a preexisting paymentsystem that is already deployed to effectively secure the system.

POS terminals 30 may perform specialized functions in differentsettings. For example, a restaurant POS terminal 30 might process aninitial authorization and a later incremental authorization forprocessing a tip. A POS terminal 30 at a rental car establishment orhotel might preauthorize a car or room for a certain number of days, andthen later request additional authorization when the car is returnedlate or when a guest checks out of the room late. These specializedfunctions are described further in connection with FIG. 9, below.

In certain embodiments, the POS terminal 30 includes a card entry device28 and a host computer 34. The card entry device 28 is a pin pad, cardswipe reader, computer keyboard, touch screen, or the like. Someimplementations of the POS terminal 30 do not include the card entrydevice 28, but rather a software component that acts as a card entrydevice. For example, a payment screen at an Internet storefront mightact as a card entry device.

The card entry device 28 of various embodiments receives payment datafrom any payment medium. The payment medium may be a payment card,electronic chip, radio frequency identification (RFID) device, or thelike. The payment data may be data encoded on a magnetic strip on theback of a card, data stored in an electronic chip, data stored in anRFID device, or any other form of stored data. As discussed below withrespect to FIG. 8, the payment data may include track data stored on theback of a payment card.

The payment data may also include a personal account number (PAN),personal identification number (PIN), expiration date, cardholder name,and/or a card security code, e.g., a three-digit code commonly found onthe back of payment cards. In addition, the payment data might includean electronic cardholder signature or biometric data, such as a digitalfingerprint. The payment data may also include a dynamic security code,such as may be found in a radio frequency identification (RFID) deviceembedded in a payment card. Many other forms of payment data may also beprovided.

The card entry device 28 passes the payment data to the host computer34. In one embodiment, the card entry device 28 is connected to the hostcomputer 34 through a link 32. The link 32 is typically a cable, serial(e.g., RS232 or USB), parallel, Ethernet, or other hardware interface.Alternatively, the link 32 is not provided and the card entry device 28is integral with the host computer 34. In another embodiment, the link32 is a software interface, such as a network socket, or somecombination of hardware and software.

The host computer 34 may be implemented as a cash register or may beconnected with a cash register. Typically, the host computer 34 is orcomprises a general purpose computer (e.g., a PC). The host computer 34receives payment data from the card entry device 28, processes the data,and transmits authorization requests to the POS server 36. When the POSserver 36 transmits authorization responses to the host computer 34, thehost computer 34 displays the response to the cardholder and processes apayment transaction.

The host computer 34 in one embodiment runs an operating system (notshown), such as Windows, Linux, Unix, or the like. The host computer 34also includes the POS terminal application 38 and the POS security layer(PSL) 40. In certain embodiments, the POS terminal application 38 andthe PSL 40 are software components, which may be implemented as scripts,executable programs, interpreted bytecode, or the like.

In one implementation, the PSL 40 is a low-level application relative tothe POS terminal application 38. For example, the PSL 40 preferably haspriority over the POS terminal application 38 to access operating systemroutines and data. In addition, the PSL 40 is preferably capable ofintercepting data intended for transmission to the POS terminalapplication 38, such as payment data. The PSL 40 may run as an operatingsystem process.

The PSL 40 in one implementation is a script running at a sufficientlylow level on the host computer 34 to capture the payment data prior tothe POS terminal application 38 receiving the payment data. In oneembodiment, the PSL 40 captures the payment data by monitoring and/oraccessing an input buffer in the card entry device 28 or in the hostcomputer 34. The PSL 40 may also be at a sufficiently low level toprevent malicious programs, such as keyloggers, packet sniffers,spyware, and viruses from obtaining the payment data. In addition, thePSL 40 encrypts the payment data and transmits the encrypted paymentdata to the POS server 36.

The POS terminal 30 communicates with the POS server 36 through anetwork 42. The network 42 may include cables, routers, switches, andother network hardware. In addition, the network 42 may be a wirelessnetwork, having wireless routers, access points, and the like. In oneembodiment, the network 42 is the same or similar to the network 12 usedin the prior art system of FIG. 1. However, in addition to the network12, the network 42 is made secure by the addition of a secure channel44. In one implementation, the POS terminal application 38 and the POSserver application 46 communicate over a non-secure channel in thenetwork 42, and the PSL 40 and a server security application (SSA) 48residing on the POS server 36 communicate over the secure channel 44.The channel 44 is secure in various implementations because encrypteddata is transmitted between the PSL 40 and the SSA 48 over the channel44.

The POS server 36 is a computer system that receives authorizationrequests from one or more POS terminals 30 and transmits theauthorization requests to a remote server, e.g., a gateway 52 over theInternet 18, a wide area network (WAN), a local area network (LAN), or aleased line. The POS server 36 therefore acts as an interface betweenthe POS terminal(s) 30 and the gateway 52. The POS server 36 may belocated at a merchant's place of business. Alternatively, the POS server36 is located at a remote data center, which may be owned or leased bythe merchant.

In addition to performing authorizations, the POS server 36 of certainembodiments also performs settlements. At the close of business or thenext morning prior to opening, the merchant, using the POS server 36,submits all of its authorized transactions to the remote server (e.g.,gateway 52). This group of transactions is typically referred to as abatch settlement. By issuing a settlement, the POS server 36 enables themerchant to receive payment or a credit for payment on the day'sauthorized credit card transactions, including transactions with debitcards used as credit cards. In some embodiments, where debit cards areprocessed as debit, the merchant receives payment from the bank withoutusing a batch settlement. When the payment cards are gift cards,settlement is also often not used.

As shown in the depicted embodiment of FIG. 2, the POS server 36includes a POS server application 46 and the SSA 48. In certainembodiments, the POS server application 46 and the SSA 48 are softwarecomponents, which may be implemented as scripts, executable programs,interpreted bytecode, or the like.

In one implementation, the POS server application 46 is a high-levelapplication relative to the SSA 48. For example, the SSA 48 may havepriority over the POS terminal application 46 to access operating systemroutines and data. In another embodiment, the SSA 48 may be capable ofintercepting data intended for transmission to the POS serverapplication 46. In still other embodiments, the SSA 48 runs as anoperating system process. Alternatively, the SSA 48 is not a lower-levelapplication than the POS server application 46.

The SSA 48 of certain embodiments replaces a preexisting communicationscomponent or is a modification thereof. As a communications component,the SSA 48 in one implementation sends and receives authorizationrequests and settlements to a remote server, such as a gateway. Becausethe SSA 48 acts as the preexisting communications component, the POSserver application 46 may communicate with the SSA 48 as if the SSA 48were the preexisting communications component. The SSA 48 of certainembodiments therefore advantageously enables the POS server application46 to send false payment data to the SSA 48 without any modification tothe POS server application 46.

The SSA 48 and the PSL 40 may monitor each other to validate productversions and to ensure that the system has not been tampered with. Thismonitoring arrangement inhibits a thief or malicious code from alteringthe SSA 48 or PSL 40 to divert, for example, payment data to thirdparties.

In one embodiment, the PSL 40 encrypts the intercepted payment data andsends the encrypted payment data to the SSA 48 over the secure channel44. The SSA 48 decrypts the encrypted payment data and creates falsepayment data by replacing all or a portion of the payment data withfalse data. The SSA 48 re-encrypts the payment data and stores theencrypted payment data on the POS server 36. Thereafter, the SSA 48transmits the false payment data to the PSL 40 through the securechannel 44. The PSL 40 then provides the false payment data to the POSterminal application 38 in place of the actual payment data. The POSterminal application 38 processes the false payment data as if it werereal payment data, providing the false payment data to the POS serverapplication 46 over the non-secure channel 42 as part of anauthorization request. Alternatively, the POS terminal application 38provides the false payment data to the POS server application 46 overthe secure channel 44. However, even when the POS terminal application38 sends the false payment data over the non-secure channel 42, thesystem is still secure as no actual payment data is stored in a database50.

In alternative embodiments, the PSL 40, rather than the SSA 48, createsthe false payment data. The PSL 40 in such embodiments then sends thefalse payment data over the secure channel 44 to the SSA 48.

The POS server application 48 also processes the false payment data asif it were real payment data. Consequently, the POS server application48 stores the false payment data in the database 50 rather than theactual payment data. Likewise, log data commonly maintained by the POSserver application 46 also includes false payment data rather thanactual payment data. Thus, in certain embodiments, no actual paymentdata is stored at the point of sale (or is stored only temporarily atcertain points in the authorization process and deleted thereafter).Even if the false payment data includes a portion of the actual paymentdata (see FIG. 8), no complete actual payment data is stored at thepoint of sale.

The POS server application 46 transmits the false payment data to theSSA 48. The SSA 48 in an embodiment then combines the false payment datawith the encrypted payment data and transmits the combined false andactual payment data over the Internet 18, leased line, or other networkto the remote server (e.g., gateway 52) as part of an authorizationrequest. The SSA 48 in another embodiment sends only the actual paymentdata or only the false payment data to the gateway 52. Moreover, the SSA48 may send the actual payment data and the false payment data to thegateway 52 in separate transmissions. In one embodiment, the SSA 48thereafter deletes all re-encrypted payment data. Alternatively, the SSA48 waits for a response from the gateway 52 prior to deleting there-encrypted payment data.

The gateway 52 in one embodiment includes one or more computer systemsacting as servers (or acting collectively as a server), remote from thePOS server 36. In various embodiments, the gateway 52 is maintained byan application service provider (ASP), which provides applicationservices and data storage for merchants. The gateway 52 may also bemaintained by a card processor, card association, issuing bank, or otherentity. For instance, the gateway 52 may be used as a card processorserver, such that the POS server 36 communicates directly (or throughone or more intermediaries) with the card processor. In someimplementations, the gateway 52 communicates with the POS server 36through a leased line or wide area network (WAN), and thereby acts as ademilitarized zone (DMZ) between the merchant network, including the POSterminals 30 and POS server 36, and the outside world. The gateway 52 inthese implementations therefore adds an additional layer of securityfrom outside attacks. The gateway 52 may also communicate with anauthorizing entity using a leased line.

A gateway security layer (GSL) 56 residing on the gateway 54 separatesthe combined false payment data and re-encrypted payment data receivedfrom the POS server 36. The gateway security layer 56 decrypts there-encrypted payment data and passes the payment data to a gatewayapplication 54, which in an embodiment (e.g., when the gateway 52 is notmaintained by a card processor) transmits the payment data to a cardprocessor for authorization. Alternatively, the gateway application 54transmits the re-encrypted payment data, or in another embodiment,encrypts the payment data with a different encryption scheme. Uponreceiving a response to the authorization request, the GSL 56 transmitsthe authorization response along with the false payment data to the POSserver 36. By providing the false payment data to the POS server 36, theGSL 56 enables the POS server 36 to identify the authorization responsewith the correct payment card (as represented by the false data),without providing the actual payment data.

Because the false payment data is identified with a specific paymentcard, the false payment data may be used as a token for an additionaltransaction with the same payment card, such as an incrementalauthorization or settlement, as described in further detail below withrespect to FIG. 9. When an additional transaction using a payment cardis requested by the POS server 36, the POS server 36 can send the tokencorresponding to that payment card to the gateway 52 to perform theadditional transaction. The gateway 52 matches the token with the actualpayment data stored at the gateway 52 in order to request authorizationor settlement from an authorizing entity. Instead of returning the falsepayment data as a token, however, the GSL 56 of some embodiments canalso return a different set of false data as a token. This false data insome instances may be a portion or derivative of the false payment data.

The gateway 52 also facilitates the performance of batch settlements incertain embodiments. In one instance, the POS terminal 30 sendsend-of-day transaction information to the SSA 36, requesting settlement.The SSA 36 transmits the false data corresponding to the end-of-daytransaction information to the gateway 52. The gateway 52 usescomponents of the false data to update final transaction amounts to besettled.

Thus, it can be seen that at various points of vulnerability in the POSsystem of FIG. 1, the payment data is secured. For instance, the PSL 40prevents the POS data from being sent in clear form to the POS terminalapplication 38. In addition, the PSL 40 transmits an encrypted versionof the data over a secure channel 44 to the SSA 48. The SSA 48 securestransaction data and log data stored in the database 50 by using falsedata and thus little or no cardholder data is stored on the database 50.Moreover, the GSL 46 secures transactions by storing actual payment dataat a secure location and by transmitting false payment data or tokendata back to the POS server 36. Consequently, opportunities toimproperly obtain payment data are reduced or eliminated entirely.

FIG. 3 illustrates the above-described card authorization processaccording to one embodiment. At step 1, the PSL 40 is invoked directlyby a user action, indirectly in response to payment data entry, orprogrammatically, e.g., by another program such as the POS terminalapplication 38. In one embodiment where the PSL is invoked directly byuser action, a hot key is used to invoke the PSL. The hot key may belocated on the POS terminal 24 or on a card entry device such as thecard entry device 28 of FIG. 2. The hot key may be a key on a keyboard,pin pad, computer screen, or touchscreen. In one embodiment, the hotkeyis a “debit” or “credit” key on a pin pad, pressed by the cardholder. Inanother embodiment, the hotkey is a payment card key pressed by anemployee of the merchant.

Additionally, the user action may include the use of a manual entrycard, which is a card used by an employee of the merchant and isconfigured to enable the customer to manually enter payment data througha pin pad, keyboard, or the like. The use of a manual key card isdescribed in greater detail below in connection with FIGS. 5-6.

In embodiments where the PSL 40 is invoked indirectly by a payment dataentry event, the payment data entry event may include a card swipe ormanual entry of payment data performed by a cardholder (e.g., acustomer) or by an employee of the merchant. In an embodiment where thePSL 40 is invoked programmatically, the POS terminal may make a functioncall by, for example, using a dynamic-linked library (DLL), whichinvokes the PSL 40.

In step 2, the PSL 40 displays a payment user interface (display screen)on the display of the card entry device 28. The payment user interfacein one embodiment is displayed in place of a preexisting payment userinterface associated with the POS server application 46. The paymentuser interface in one embodiment is a substitute payment screen, whichenables a user (e.g., cardholder or employee of the merchant) to providepayment data directly to the PSL 40. The substitute payment screen mayalso provide peace of mind to the user by displaying a messagedescribing that the payment data is secure. In an alternativeembodiment, the substitute payment screen is hidden from the user and istherefore transparent to the user.

The payment user interface of some embodiments pops over or otherwiseoverlays or replaces the preexisting user interface. The payment userinterface may have a similar look and feel to the preexisting userinterface, or the payment user interface may have a different look andfeel. In other embodiments, the payment user interface is thepreexisting user interface rather than a substitute payment userinterface.

The PSL 40 also captures payment data provided by the cardholder. ThePSL 40 of certain embodiments intercepts the payment data and preventsother programs from accessing the data. By capturing the payment dataprior to other programs capturing the data, the PSL 40 in variousimplementations acts as a keylogger.

In one embodiment, the PSL 40 is a hook-based keylogger, e.g., akeylogger that uses operating system routines (e.g., theSetWindowsHookEx API (application programming interface) in Windowsimplementations) to capture incoming data. Similarly, the PSL 40 may useother operating system routines (e.g., the GetKeyboardState API inWindows implementations) to obtain keystrokes prior to the keystrokesbeing received by any active window. Alternatively, the PSL 40 may be akernel-based keylogger, receiving input/output (I/O) requests that aresent to the input device driver (e.g., the card entry device 28). In onesuch embodiment, the PSL 40 employs a device-level driver that sitsabove the keyboard driver (e.g., between the input device driver andother operation system functions or applications), and hence is able tointercept I/O requests. Moreover, the PSL 40 may also be a handleinjection keylogger by injecting characters into a window and therebybypassing the input device. As a keylogger, the PSL 40 captures pin padkeystrokes, keyboard keystrokes, track data, signature data, biometricdata, and the like. Capturing this data allows the PSL 40 to preventmalicious programs from accessing the data and also allows the PSL 40 toprevent the data from reaching the POS terminal application 38. Thus,the PSL 40 of certain embodiments increases the security of the POSterminal 30.

Turning to step 3, the PSL 40 transmits the captured payment data to theSSA 48 over a secure channel. In one embodiment, the channel is securedue to an encryption scheme performed by the PSL 40 on the payment data.The encryption scheme may include a mixed public/private key(asymmetric/symmetric key), a public key, a private key, or anotherencryption scheme. In one embodiment, an IPSEC or PKI protocol is usedin the encryption scheme. One example implementation of the encryptionscheme includes a mixed public/private key stored in real-time, inrandom-access memory (RAM). The encryption and decryption may be dynamicin nature, in that the encryption scheme may create a new public/privatekey pair each time the SSA 48 is started. In addition, the keys in theencryption scheme may be implemented using one or more encryptionalgorithms. For instance, a blowfish algorithm, twofish algorithm, a3DES (Triple Data Encryption Standard) or AES (Advanced EncryptionStandard) algorithm, or other algorithm may be used to encrypt thepayment data at the PSL 40.

The SSA 48 in one embodiment decrypts the encrypted payment data andreturns false payment data to the PSL 40 in step 4. Alternatively, theSSA 48 does not decrypt the payment data. The SSA 48 generates falsepayment data such that the POS terminal 30 and the POS server 36 will beable to process the false payment data as if it were real payment data.In one embodiment, the SSA 48 generates the false payment data using arandom-number generator. In another embodiment, the SSA 48 generates thefalse payment data sequentially. For example, a personal account number(PAN) from a first payment card may be replaced with numbers from asequence of false data, and a second PAN may be replaced with successivenumbers in the sequence of false data. A more detailed example of falsedata is described below with respect to FIG. 8.

The SSA 48 reencrypts the payment data or provides additional encryptionto already encrypted payment data. The SSA 48 stores the encryptedpayment data on the POS server 36. In some implementations, the SSA 48provides additional encryption even when the payment data is alreadyencrypted because the SSA 48 can be used without the PSL 40 to processtransactions from the POS server 36 and/or POS terminal 30. In suchcircumstances, it may be desirable to encrypt any data transmitted fromthe SSA 48 over a public network. Additionally, other non-publicinformation that may already exist in the POS server 36 may be encryptedand sent to a data center using the SSA 48. Depending on the merchant,this information might include pre-registered information such as SocialSecurity numbers, medical patient IDs, addresses, and the like.

In one embodiment, the SSA 48 provides two types of encrypted paymentdata, including an “undecryptable” version and a decryptable version.The undecryptable version is decryptable at the gateway 52 but not atthe merchant location (e.g., at the POS terminal 30 or POS server 36),and the decryptable version is decryptable at the merchant location. Asdescribed more fully below in connection with FIG. 7, the undecryptableversion may be used to process credit transactions and offline debittransactions, and the decryptable version may be used to process onlinedebit transactions. However, in alternative embodiments, such as whenonline debit transactions are not used by the merchant, the SSA 48provides only an undecryptable version of the payment data. Moreover, instill other embodiments, the PSL 40, rather than the SSA 48, providesthe undecryptable and decryptable versions of encrypted payment datawhen the PSL 40 originally encrypts the payment data. In one suchembodiment, the SSA 48 provides additional encryption to thealready-encrypted payment data. In addition, the SSA 48 may generatefalse payment data without knowing the contents of the actual paymentdata.

In step 5, the PSL 40 passes the false payment data to the POS terminalapplication 38. The POS terminal application 38 receives the falsepayment data as if it were the real payment data. Because the POSterminal application 38 has only false payment data, malicious softwareand hardware in communication with the POS terminal 30 cannot access theactual payment data.

In step 6, the POS terminal application 38 passes the false payment datato the POS server application 46 on the POS server 36 typically over anon-secure channel as part of an authorization request. Because falsedata is used, the payment data is made secure.

In step 7, the POS server application 46 records the transaction withthe false payment data in the database 50. The transaction data mayinclude the false payment data along with information regarding purchaseprice, items purchased, and the like. The transaction data is used insome applications for generating reports, generating batch settlements,and for processing incremental or authorizations (see FIG. 9 below). Inaddition, the POS server application 46 stores log data in the database50. The log data may include a subset or all of the transaction data andmay also include additional data. The log data may be used to provideaccess to a technician for troubleshooting the POS terminal 34 or thePOS server 36. Because false transaction and log data are stored in thedatabase 50, the payment data is secure.

In step 8, the POS server application 48 sends a payment orauthorization request message to the SSA 46. Thereafter, in step 9 theSSA 46 modifies the payment request message by combining the falsepayment data with the re-encrypted payment data. The SSA 48 then sendsthe combined payment data to the gateway security layer (GSL) 56 in step10.

At the gateway 52, the GSL 56 then decrypts the encrypted payment datain step 11 to recover the actual payment data. The GSL 56 in step 12then passes the actual payment data to the gateway application 54.Alternatively, the GSL 56 reencrypts the data prior to sending the datato the gateway application 54. In another embodiment, the GSL 56 doesnot decrypt the encrypted data received from the POS server 36, butinstead passes the encrypted data to the gateway application 54. In step13, the gateway application 54 then transmits the payment data to a cardprocessor, which is an intermediary in eventually obtaining anauthorization response from a central location such as an issuing bank.

The processor returns the payment data and a payment request response tothe gateway application 54 in step 14. The gateway application 54 passesthe payment data and payment request response to the GSL 56 in step 15.Thereafter, the GSL 56 sends the false payment data, rather than theactual payment data, along with the payment request response to the SSA48. By sending the false data, the GSL 56 enables the SSA 48 to identifythe payment request response with the correct payment card withoutsending the actual payment data to the SSA 48.

Turning to FIG. 4, an alternative process flow for processing paymentcard transactions is depicted. This alternative process flow might beused, for example, with legacy POS terminals 30 that have a directcommunications interface (e.g., not via an SSA or the like) to aparticular gateway or processing platform (e.g. a bank's proprietaryfront end). In the alternative process flow of FIG. 4, a POS terminal 30is in communication with a gateway 64 and a POS server 8. In addition, adatabase 50 is in communication with, or maintained on, the POS server8. At step 1, the PSL 60 is invoked directly by a user action,indirectly in response to payment data entry, or programmatically, e.g.,in a similar manner as described with respect to FIG. 3 above.

Thereafter, in step 2 the PSL 60 displays a payment user interface andcaptures the payment information. In step 3, the PSL 60 sends thecaptured payment information to a gateway security application 62 over asecure channel, which may be the Internet, a leased line, or othernetwork. In one embodiment, the PSL encrypts the data prior totransmission, thereby securing the channel.

In step 4, the GSA 66 returns false payment data to the PSL 60.Consequently, no actual payment data is stored on the POS terminal 34 orthe POS server 8. However, if an online debit transaction is used, theGSA 66 may also provide a decryptable version of the payment data toenable the POS terminal 30 to process the online debit transaction. Inthe alternative, the PSL 60 uses a decryptable version of the paymentdata to process the online debit transaction. The PSL 60 in step 5passes the false payment data to the POS terminal application 38. ThePOS termination application 38 processes the false payment data as if itwere actual payment data.

The POS terminal application 38 then in step 6 passes the false paymentdata to the POS server application 14. In step 7, the POS serverapplication 14 records the transaction with the false payment data inthe database 50. Because false payment data is stored in the database50, the payment data is less vulnerable to theft.

Thereafter, the POS server application 14 in step 8 sends a paymentrequest or authorization request message to the gateway 64 using thefalse payment data. The gateway security application 66 in step 9transmits the actual payment data and a payment request message to aprocessor. Thus, except when the encrypted actual payment data istransmitted to the GSA 66, only false payment data is used in theauthorization transaction. Finally, the gateway receives the paymentdata and the payment request response from the processor and forwardsthe response on to the POS server application 46.

Certain components described in the alternative process flow may beprovided to a preexisting non-secure POS system to secure the POSsystem. In one embodiment, the PSL 40 is provided to augment or retrofita preexisting POS system. In addition, the GSA 66 may be provided toreplace or to augment a preexisting gateway 64. However, in the depictedembodiment, no component is added to augment the preexisting POS server8. Advantageously, fewer components are therefore used to secure the POSsystem in the alternative process flow of FIG. 4.

FIGS. 5 and 6 illustrate various embodiments for invoking a PSL andcapturing payment data. FIG. 5 depicts a method 100 for directlyinvoking a PSL and capturing payment data. FIG. 6 depicts a method 200for indirectly invoking a PSL and capturing payment data. The methods100, 200 may be performed by any of the POS terminals described above,and as part of the process of FIG. 3 or FIG. 4.

Referring to FIG. 5, at 102, the method 100 determines whether a useraction has been detected. The user action may include, for example, ahotkey press or a manual key card swipe. If a user action has not beendetected, the method 100 returns to 102. In one embodiment, the methodat 102 therefore listens for the pressing of a hotkey, which may be akey on a keyboard, pin pad, a button on a computer or touch screen, orthe like. The pressing of a hotkey may be, for example, the pressing ofa “payment type” key on a pin pad of the card entry device.

If a user action was detected, the method 100 invokes the PSL at 104. Inone embodiment, the PSL is resident in memory prior to the key press,listening for a user action, payment data entry, or program call(described below with respect to FIG. 6). In one such embodiment, thePSL is invoked by activating functions in the PSL that enable thecapture of payment data. In an alternative embodiment, the PSL isinvoked by being loaded into memory.

At 106, the method 100 displays a substitute payment screen. In oneembodiment, the payment screen is a substitute payment screen displayedin place of an original payment screen supplied by a POS manufacturer.The substitute payment screen may have a similar look and feel to theoriginal payment screen; however, payment data entered into thesubstitute payment screen is captured by the PSL. The substitute paymentscreen may also look different from the original payment screen orinclude fewer or more features than the original payment screen. Thesubstitute payment screen enables entry of payment data directly intothe PSL.

The method 100 continues at 108 by determining whether the user actionincluded the entry of a manual key card. The manual key card in oneimplementation is a card used by an employee of the merchant to preparethe POS terminal for receiving manual entry data. Manual entry dataincludes payment data typed into a keyboard, PIN pad, or the like, whichmay be entered if the card swipe reader is not working or is notavailable to the cardholder, such as in online or telephone catalogtransactions. If the user action included use of a manual key card, themethod 100 proceeds to capture the manually-entered data at 110.Otherwise, if another user action was used, the method 100 proceeds tocapture swiped data of the payment card at 112.

In another embodiment, manual entry of payment data may be done withoutusing a manual entry card. For example, in one embodiment, a cardholderinvokes the PSL through a hotkey press and manually enters the paymentdata in the substitute payment screen.

Referring to FIG. 6, the method 200 determines whether payment dataentry has been detected at 202. If payment data entry has not beendetected, the method 200 returns to 202. In one embodiment, the methodat 202 therefore listens for payment data entry, which may include acard swipe, manual entry of payment data, or the like. The payment dataentry may performed by a cardholder or employee of the merchant invarious embodiments.

If payment data entry was detected, the method 200 invokes the PSL at204, which captures the payment data at 206. In one embodiment, the PSLis resident in memory prior to the payment data entry, listening for auser action (see FIG. 5) or payment data entry. In one such embodiment,“invoking” the PSL means to activate the PSL to enable the PSL tocapture the payment data. In an alternative embodiment, the payment dataentry invokes the PSL by causing the PSL to be loaded into memory.

In one embodiment, a substitute payment screen is not used to capturethe payment data because the payment data entry provided the paymentdata. In an alternative embodiment, the substitute payment screen isalso displayed in the method 200. In one such embodiment, the substitutepayment screen enables the cardholder to enter PIN data, signature data,biometric data, or the like.

While not shown in FIG. 6, the PSL may also be invoked by a programcall. In one such implementation, a software component on the POSterminal may make a function call by, for example, using adynamic-linked library (DLL), which invokes the PSL.

FIG. 7 is a flowchart diagram illustrating an embodiment of a method 300for encrypting payment data. The method 300 may be performed by any ofthe POS systems described above and as part of the process of FIG. 3 or4. In particular, the method 300 is performed by the SSA in oneembodiment. Advantageously, the method 300 enables online debittransactions to be secured. In some implementations, the term “onlinedebit” denotes using a PIN to complete a debit transaction, and the term“offline debit” refers to using a signature to complete a debittransaction. Online debit is often referred to colloquially as a “debit”transaction, and “offline debit” is often referred to as a “credit”transaction.

At 304, the method 300 encrypts payment data with an “undecryptable”cipher. In one embodiment, the data is undecryptable at the point ofsale, e.g., at the POS terminal or POS server. However, the data may bedecrypted at a gateway or other remote server.

At 306, the method 300 encrypts the payment data with a decryptablecipher. In one embodiment, the data is decryptable at the point of sale,e.g., at the POS terminal or POS server. The method 300 in oneimplementation encrypts the data with the decryptable cipher at the sametime or substantially the same time as the method 300 encrypts the datawith the undecryptable cipher.

The method 300 next determines whether an online debit transaction istaking place at 308. If the transaction is not online debit (e.g., it isan off-line debit, credit, or gift card transaction), the method 300destroys the decryptable version at 310. If, however, the transaction isonline debit, the method 300 proceeds to decrypt the decryptable versionof the payment data at 312. The decryptable version is destroyed by theSSA, although in alternative embodiments, the PSL performs thisfunction. Thereafter, the method 300 encrypts the PIN using thedecrypted payment data to create an encrypted PIN block at 314. Once theencrypted PIN block is created, the method 300 destroys the decryptableversion of the payment data at 316. As before, the decryptable versionis destroyed by the SSA, but the PSL may also perform this function. Inaddition, in an alternative embodiment, the method 300 may be applied toa credit card, gift card, or other card having a PIN, rather than adebit card.

One example implementation of the method 300 is as follows. An SSAencrypts payment data received from a PSL with an “undecryptable” cipherat 304 and a decryptable cipher at 306. The SSA determines whether thetransaction is online debit at 308. If the transaction is not onlinedebit, the SSA deletes the decryptable version of the data at 310. TheSSA may delete the data upon detecting a non-online debit transaction,or the SSA may employ a time-out period (e.g., 30 seconds), after whichthe decryptable version will be automatically destroyed. In addition,the decryptable version may be stored in volatile memory (memory thaterases on power-down), such as in random access memory (RAM). In oneembodiment, the time-out period is adjusted to balance transactionalreliability with security. Alternatively, the SSA determines that thetransaction is online debit and sends the decryptable version to thePSL, which decrypts the decryptable version of the payment data at 312.The PSL then provides the decrypted payment data to the pin pad, whichat 314 encrypts the PIN using some or all of the payment data (e.g., thePAN or full track data). Once the PIN is encrypted or after a time-outperiod, the SSA destroys (permanently deletes the only copy of) thedecryptable version of the payment data stored on the POS server at 316.In addition, if a copy of the decryptable version is stored on the POSterminal, the PSL also destroys this data.

Some businesses do not accept online debit transactions or any debittransactions. In these businesses, the method 300 may be configured toprovide only an undecryptable version of the payment data. Thus, theremay be no need to store a decryptable version.

Turning to FIG. 8, various formats of payment data are shown, some orall of which are generated during the process flow described above undereither of FIG. 3 or 4. FIG. 8 illustrates actual data 410, originallypresented by the cardholder. This actual data 410 is encrypted by a PSLand becomes encrypted data 430. Thereafter, an SSA decrypts theencrypted data 430 and replaces the actual data 410 with false data 450.In addition, the SSA re-encrypts the actual data 410 to generatere-encrypted data 460. The SSA combines the false data 450 and there-encrypted data 460 to create combined data 470, which the SSAtransmits to a gateway.

The various formats of payment data shown are depicted as track data.The actual data 410 is contained in a magnetic swipe on the paymentcard. This magnetic swipe includes one or more “tracks” of data. Manydebit and credit cards have three tracks of data, which are typicallyreferred to as “track 1,” “track 2,” and “track 3.” Of these tracks,track 2 is often used by vendors to obtain payment data from the paymentcard. An example of track 2 data is shown in FIG. 8 as actual data 310.

The actual data 310 includes a start sentinel 412, represented by a “;”character. The start sentinel 412 is used, for example, by parsingsoftware to indicate the start of track 2 data. Following the startsentinel 412, a PAN 414 is shown. The depicted PAN 414 includes 16digits. In alternative embodiments, more or fewer digits are included inthe PAN 414.

Following the PAN 414, a field separator 416 is shown, denoted by the“=” character. The field separator 416 enables parsing software todistinguish between the PAN 414 and data following the PAN 416. Afterthe field separator 416, ancillary data 418 is shown. The ancillary data418 may include the expiration date of the card, the PIN of the card,and other discretionary data determined by the card issuer. In thedepicted embodiment, the first four digits of the ancillary data 418 arereserved for the card expiration date using the format YYMM (“0101”). Anend sentinel 420 (“?”) follows the ancillary data 418 to mark the end ofthe track.

In certain embodiments, track 1 data (not shown) is used instead of orin addition to track 2 data. One possible format of track 1 data mightbe the following: “% B PAN A Cardholder Name ̂ Ancillary data ?”. Likethe track 2 data, the track 1 data includes start and end sentinels (“%”and “?”), one or more field separators (“̂ ”), the PAN, and ancillarydata. The track 1 data also includes a format code (“B”), which mayvary, and the cardholder name. While the remainder of FIG. 8 describes aspecific example using track 2 data, track 1 data may also be usedinterchangeably or with slight modifications. Likewise, though notshown, in some implementations track 3 data may also be used.

During the process flow described under FIGS. 3 and 4 above, the actualdata 410 is encrypted by a PSL to generate encrypted data 430. Theencrypted data 430 includes a block 432 of alphanumeric and/or symbolicrepresentations of the actual data 410.

The encrypted data 430 is decrypted by the SSA, and the SSA replaces theactual data 410 with false data 450. In one embodiment, the false data450 looks substantially similar to the actual data 410. Because thefalse data 450 is similar to (in the same format as) the actual data410, a POS terminal and POS server can process the false data 450 as ifit were the actual data 410 without being aware of processing false data450. Thus, in one embodiment the false data 450 has a card-swipecompatible format.

In the depicted embodiment, the false data 450 is a modified version ofthe actual data 410. The false data 450 includes the same start and endsentinels 412, 420 and the same field separator 416. However, a PAN 452of the false data 450 differs from the PAN 414 of the actual data 414.In addition, ancillary data 454 of the false data 450 differs from theancillary data 418 of the actual data 410.

The PAN 452 of the false data 450 in one implementation retains thefirst four digits (“1234”) and the last four digits (“3456”) of the PAN414 of the actual data 410. Between the first four and last four digits,the digits of the actual data 410 are replaced with false digits 456,e.g., “00000000” in the depicted example. In addition, the ancillarydata 454 of the false data 450 includes false data in the depictedembodiment. In the depicted embodiment, this false data completelyreplaces the ancillary data 418 of the actual data 410. Alternatively,the ancillary data 454 does not include false data.

The false data 450 for a particular payment card is unique and distinctfrom other false payment data 450 corresponding to other payment cards.In one embodiment, this uniqueness is achieved by combining the falsedigits 456 between the first and last four digits of the PAN 452. Inaddition, the ancillary data 454 may be generated to provide uniquefalse data 450.

The false digits 456 may be generated randomly. Alternatively, the falsedigits 456 are generated incrementally, where each successive paymentcard presented at the POS is provided a successive number in a sequence.For example, the false digits 456 may be incremented from 11111111 to22222222 and so on down to 99999999. In addition, the false digits 456may be generated from an algorithm which uses the date, time, and/or theorigin of the transaction to derive a set of digits. In anotherimplementation, the false digits 456 are generated according to anothertype of algorithm or a combination of the above-described algorithms.Likewise, the false ancillary data 454 may be generated randomly,sequentially, or algorithmically.

In another embodiment, the false data 450 is generated such that thefalse data 450 fails the Luhn Modulus 10 algorithm (“the Luhn test”),described in U.S. Pat. No. 2,950,048, titled “Computer for VerifyingNumbers,” which is hereby incorporated by reference in its entirety. TheLuhn test detects a valid card number by performing a checksum of thedigits of the card number. The false data 450 may therefore be generatedsuch that a checksum of the digits of the false data 450 indicates thatthe false data 450 is an invalid payment card number. Consequently, thefalse data 450 in this embodiment cannot be used fraudulently as a validcard number.

The false data 450 may be generated to fail the Luhn test in a varietyof ways. In one embodiment, false data 450 is first generated thatpasses the Luhn test. Then, the false data 450 is modified so that it nolonger passes the Luhn test, e.g., by changing a digit in the false data450. For example, if one of the digits in the false data 450 is a 5, thealgorithm could replace the 5 with any of the numbers 0-4 or 6-9,causing the false PAN to fail the Luhn test.

In addition or as an alternative to the Luhn test, invalid ranges ofcard numbers may be used to generate the false data 450. For example,different ranges of invalid card numbers may be designated by differentcard associations (e.g., Visa, American Express, or the like); a falsedata generation algorithm may then be used which ensures that all falsecard numbers generated for a particular card type (e.g., Visa) fallwithin the corresponding invalid range. In one embodiment, at least aportion of the false data 450 is thus derived or selected from a rangeof invalid card numbers created by one or more card associations. Forexample, if a card association uses the range 4000000000000000 to4999999999999999 for valid PAN numbers, at least a portion of the falsedata 450 could take on a number from 0000000000000000 to3999999999999999 or from 5000000000000000 to 9999999999999999.Advantageously, false data 450 derived from these ranges in certainembodiments cannot be used for fraudulent authorizations. Moreover, inone implementation, the false data 450 may be derived from an invalidrange of card numbers and also be generated to fail the Luhn test.

False data 450 generated to fail the Luhn test or generated from aninvalid range of card numbers can be used beneficially as a token foradditional transactions. In one embodiment, the false data 450 is useddirectly as a token, or alternatively, a token is derived from the falsedata 450. In one embodiment, the token includes three parts. These partsmay include some portion of the first four digits of the PAN, followedby seven digits of false data, followed by the last four digits of thePAN. Because the token is an invalid card number, the token may be usedin certain complex POS systems for additional or recurring transactions.In addition, this implementation of a token may allow greaterflexibility for subsequent transaction processing, such that the tokencan be used to process subsequent transactions in a similar way toexisting tokenization models.

Some POS terminals and/or servers may be changed to disable the use ofthe Luhn test in order to facilitate using false data 450 that fails theLuhn test. As some POS terminal and/or server manufacturers have theLuhn test enabled on a payment-type basis (e.g., credit card paymenttype, debit card payment type, or the like), this particular feature canbe disabled for some or all payment-types accepted by a particularmerchant. Thus, in various embodiments the false data 450 has acard-swipe compatible format that can be processed by the POS system,but the false data 450 is an invalid card number.

Because the first and last four digits of the PAN 414 are retained inthe false PAN 452 in some variations, the combination of random,sequential, or algorithmically-defined digits and the first and lastfour digits of the PAN 452 will likely be unique from false data 450generated for other payment cards. If a non-unique number is generated,in one embodiment the SSA re-generates the false data 450 until a uniquenumber is found.

The false digits 456 may also be tied to a particular transaction. Thus,in one example, a single payment card used in multiple transactions maybe assigned a unique set of false data 450 for each transaction.Alternatively, successive transactions use the same false data 450.

While one example of the false data 450 has been described, the falsedata 450 may be implemented in other ways. For instance, fewer or morethan the first and last four digits of the actual PAN 414 may beretained, or additional portions of the ancillary data 418 may beretained. In addition, the ancillary data 418 may be falsified intofalse ancillary data 454 randomly, sequentially, or algorithmically.Moreover, in one embodiment, one or more of the start and end sentinels412, 420 or field separator 416 are replaced with false data. Inaddition, although numerals have been used to represent false data, inone embodiment, the false data 450 includes false alphanumeric orsymbolic characters.

The false data 450 or portions thereof (e.g., the false digits 456)cannot be transformed into the actual data 410 in some embodimentsbecause it is generated by a random process, sequence, or algorithm thatis not based on the actual data 410. Thus, the false data 450 of suchembodiments bears little or no relation to the actual data 410. Thefalse data 450 of such embodiments is correlated with the actual data410 only by the SSA combining the false 410 and re-encrypted data 460together for transmission to the gateway. Thus, when the SSA deletes there-encrypted data 460 after transmission, only the gateway knows theactual data 410 and to which actual data 410 the false data 450corresponds. Thus, the false data 450 of certain embodiments helpssecure the POS system.

FIG. 8 also depicts the re-encrypted data 460. This data 460 isgenerated by the SSA after the SSA decrypts the encrypted data 430received from the PSL. While only one block of data is shown, there-encrypted data 460 may actually be two data blocks—one undecryptabledata block and one decryptable data block (see FIG. 7). The two datablocks may have different values.

The SSA combines the false data 450 and the re-encrypted data 460 intocombined data 470. The SSA may use either the undecryptable ordecryptable data block to create the combined data 470. Although thecombined data is formed by concatenation in this example, any method ofcombining the false 450 and re-encrypted data 460 may be used providedthat the method is known to the gateway. The SSA provides the combineddata 470 to the gateway, which decrypts the re-encrypted data 460 storedin the combined data 470 to recover the actual data 410. Though notshown, the gateway may also re-encrypt the actual 410 data in a formatthat is decryptable by the authorizing entity (e.g., issuing bank). Thegateway may instead not decrypt the re-encrypted data 460, but ratherpass the re-encrypted data 460 directly to the authorizing entity.

Turning to FIG. 9, embodiments of a method 500 for obtaining incrementalauthorizations or settlements are shown. Payment data is often used toperform incremental authorizations or settlements. For example, in therestaurant environment, the payment card is first authorized for theamount of the bill. However, frequently the merchant adds incrementalcharges, such as tips and tabs to the bill after the cardholder hasleft. In order to complete the incremental transaction, the merchantretains the payment data.

Similarly, in lodging and rental industries, incremental authorizationsare used. For example, hotels and car rental businesses use payment cardauthorizations to make reservations. Storing payment data enables hotelsand car rental businesses to charge multiple items to a single invoice.Hotel customers often want and expect the ability to charge items totheir room from the gift shop, restaurant, spa, and the like. In somecases, it may not always be possible to ask the cardholder to present acard to cover the cost of incidentals. The cardholder may have alreadychecked out, for instance, prior to the discovery of a depleted minibar, or they may have said they would return a car tank full of gas, butin fact did not.

In addition, mail order, telephone order, and online businesses oftenoperate using a “book and ship” model. In this model, the order isplaced, but the credit card is not charged until the order is actuallyshipped. In these cases, payment data is retained until the order isshipped and the card is charged for the amount of the order. Moreover,merchants who charge monthly memberships, such as spas, clubs, and gyms,also store the payment data in order to process these monthly charges.

Accordingly, FIG. 9 illustrates a method 500 for obtaining incrementalauthorizations or settlements. At 502, the method obtains payment data.The payment data may be obtained, for example, by the PSL. The method500 then stores false data 504 in place of the payment data. In oneembodiment, the POS server application stores false data provided by thePOS terminal application as if it were the real payment data. At 506,the method obtains an initial authorization or settlement 506 using thefalse data. This step may include the substeps of requesting anauthorization or settlement using the POS terminal application and/orSSA, receiving the authorization or settlement with the gateway, andreceiving the authorization or settlement response from the gateway atthe SSA.

Thereafter, the method 500 determines at 508 whether an incrementalauthorization or a settlement is to be performed. In one embodiment,this determination is made by the POS terminal application. If there isno such authorization or settlement, the method ends. Otherwise, themethod 500 uses the stored false data at 510 to obtain an incrementalauthorization or delayed settlement by using, for instance, the SSA torequest the authorization or settlement. Because the method 500 usesfalse data to perform the additional authorizations or settlements,sensitive payment data does not need to be stored at the merchantlocation to perform additional authorizations or settlements. As aresult, the method 500 increases the security of payment cardtransactions.

In addition to the embodiments described above, some or all of thevarious systems and methods described herein may be employed with anonline store over the Internet. For example, the point of sale mayinclude a shopping cart program at the online store, and the onlinestore may process all or a portion of a transaction using false data.Moreover, at least a portion of the systems and methods described hereinmay be implemented at a telephone call center. For instance, an operatormay take payment data from a purchaser over the telephone and enter thepayment data into a secure POS terminal, which performs all or a portionof the transaction using false data.

Moreover, although the POS terminal and the POS server have beendescribed as separate devices, in certain embodiments the POS terminaland the POS server are a single physical device, or the functions of thePOS terminal and server are performed by a single device. As a result,in one embodiment some or all of the functions of the POS terminal andserver are implemented, except that no network is used to communicatebetween the POS terminal and server. Additionally, some or all of thefunctions of the POS terminal may be performed by the POS server, andvice versa. Other implementations may also be employed, as will beunderstood by those of skill in the art.

Those of skill will further appreciate that the various illustrativelogical blocks, modules, components, and process steps described inconnection with the embodiments disclosed herein may be implemented aselectronic hardware, computer software, or combinations of both. Toclearly illustrate this interchangeability of hardware and software,various illustrative components, blocks, components, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled artisans can implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the present inventions.

In addition, while certain embodiments of the inventions have beendescribed, these embodiments have been presented by way of example only,and are not intended to limit the scope of the inventions. Indeed, thenovel methods and systems described herein may be embodied in a varietyof other forms; furthermore, various omissions, substitutions, andchanges in the form of the methods and systems described herein may bemade without departing from the spirit of the inventions. Theaccompanying claims and their equivalents are intended to cover suchforms or modifications as would fall within the scope and spirit of theinventions.

1. A non-transitory computer-readable medium having stored thereon apoint-of-sale (POS) security layer that communicates with a POSapplication and a POS server, the POS security layer comprisingexecutable instructions that cause a computing system to at least:intercept actual payment data supplied by a user for performing apayment card transaction, such that the actual payment data is not madeavailable to the POS application; pass the false payment data to the POSapplication for use in place of the actual payment data, thereby causingthe POS application to transmit the false payment data to the POS serverin place of the actual payment data; and transmit the actual paymentdata to the POS server.
 2. The computer-readable medium of claim 1,wherein the POS application comprises a shopping cart program of anonline store.
 3. The computer-readable medium of claim 1, wherein thePOS security layer is configured to obtain at least a portion of thefalse payment data from a security application that runs on the POSserver.
 4. The computer-readable medium of claim 1, wherein the falsepayment data comprises a portion of the actual payment data.
 5. Thecomputer-readable medium of claim 1, wherein the POS security layer isfurther configured to encrypt the actual payment data.
 6. Thecomputer-readable medium of claim 1, wherein the POS security layer iscapable of being invoked indirectly by entry of the payment data intothe POS application.
 7. The computer-readable medium of claim 1, whereinthe POS security layer is capable of being invoked programmatically. 8.The computer-readable medium of claim 1, wherein the actual payment datais transmitted to the POS server over a secure channel.
 9. Thecomputer-readable medium of claim 1, in combination with a computingdevice that is configured to executed the POS security layer.
 10. Amethod of securing payment transactions, the method comprising: by acomputing system comprising computer hardware: intercepting payment datasupplied by a user for performing a payment card transaction, thepayment data comprising actual payment data from a payment medium;accessing false payment data that does not represent valid card data;and providing the false payment data to the POS application, the falsepayment data configured to be processed as if it were the actual paymentdata, thereby causing the POS application to transmit an authorizationrequest using the false payment data in place of the actual paymentdata.
 11. The method of claim 10, further comprising displaying asubstitute payment display configured to facilitate the intercepting ofthe payment data.
 12. The method of claim 10, further comprisingencrypting the payment data.
 13. The method of claim 10, wherein thefalse payment data has a card-swipe compatible format.
 14. The method ofclaim 13, wherein at least a portion of the false payment data isderived from a range of card numbers regarded as invalid by one or morecard associations.
 15. A system for securing payment transactions, thesystem comprising: a computing device programmed to implement a POSsecurity layer configured to: capture payment data intended to beprovided to a POS application, the payment data comprising actual carddata from a payment card; obtain false payment data that does notrepresent valid card data; and provide the false card data to the POSapplication to thereby cause the POS application to transmit anauthorization request using the false card data in place of the actualcard data.
 16. The system of claim 15, wherein the POS security layer isfurther configured to provide a substitute payment display configured tofacilitate the intercepting of the payment data.
 17. The system of claim15, wherein the POS security layer is further configured to encrypt thepayment data.
 18. The system of claim 15, wherein the false payment datahas a card-swipe compatible format.